Fix shard ranges in seedtos3.sh #15
Conversation
The shard_seeder tool (in opencbdc-tx) computes shard range as 256/#shards, i.e., rounds down the range. This script computes it as 255/#shards +1, i.e., rounds it up. This doesn't matter if num shards is a power of 2, but for other values, the tool and script differ, causing errors in seed generation. The quick fix in this commit is to calculate the range by rounding down, as the tool does, and to ensure that the last range is extended, if needed, to the 1-byte max or 255. Signed-off-by: Ram Darbha <[email protected]>
|
concept ACK! This has been a small thorn in our side for a while (it practically limits pre-seeded tests from the test controller to power-of-two logical shard counts). We discussed this offline, and the longer-term fix is to unify all ancillary tooling (this script as well as the Till then, this is an excellent quick-fix to allow testing of less-even shard topologies to go ahead unblocked. Will try to test/approve/merge early next week! |
|
(I'm working to close opencbdc-tx#258 since we're actively testing it, before redeploying our TC to test this. Sorry for the delay!) |
There was a problem hiding this comment.
Testing for #258 is a touch delayed, so I had a chance to redeploy the TC and test this without interrupting other things.
tACK! Brings the range-calculation in the TC's script inline with the one used by the shard-seeder tool (avoiding silly seed name-mismatching errors).
Merging!
The shard_seeder tool (in opencbdc-tx) computes shard range as 256/#shards, i.e., rounds down the range. This script computes it as 255/#shards +1, i.e., rounds it up. This doesn't matter if num shards is a power of 2, but for other values, the tool and script differ, causing errors in seed generation. The quick fix in this commit is to calculate the range by rounding down, as the tool does, and to ensure that the last range is extended, if needed, to the 1-byte max or 255.